The attached logfile shows a thread/data race detected by TSan (ThreadSanitizer). * Specific information about this bug It looks like TSan would really like there to be some sort of cross-thread locking on JSScript::warmUpCount. I don't know how well that would interact with the JIT, though... * General information about TSan, data races, etc. Typically, races reported by TSan are not false positives, but it is possible that the race is benign. Even in this case though, we should try to come up with a fix unless this would cause unacceptable performance issues. Also note that seemingly benign races can possibly be harmful (also depending on the compiler and the architecture) [1][2]. If the bug cannot be fixed, then this bug should be used to either make a compile-time annotation for blacklisting or add an entry to the runtime blacklist. [1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong [2] _How to miscompile programs with "benign" data races_: https://www.usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf

I am seeing this race in the shell as well.

This removes a ton of TSAN failures.

Comment on attachment 8715032 [details] [diff] [review] tsan_warmUpCount-v0.diff Review of attachment 8715032 [details] [diff] [review]: ----------------------------------------------------------------- Nice, thanks for fixing this! ::: js/src/jsscript.h @@ +1050,4 @@ > * or has had backedges taken. When running in > * ion, also increased for any inlined scripts. > * Reset if the script's JIT code is forcibly > * discarded. */ Nit: can we move this whole comment before the warmUpCount definition (and reformat to 80 columns)?

https://hg.mozilla.org/integration/mozilla-inbound/rev/772dbb329a151adf98805a3b0cd5c713f5733e08 Bug 1141579 - Synchronize access to warmUpCount; r=jandem

Done!